home *** CD-ROM | disk | FTP | other *** search
/ Acorn User: China / Acorn User China CD-ROM (UK) (Disc B) / Acorn User China CD-ROM (UK) (Disc B).bin / STUTTGART / DATABASE / ULTIMATE / a252aud.txt < prev    next >
Encoding:
Internet Message Format  |  1993-08-09  |  6.3 KB
  1. From: mark@acorn.co.uk (Mark Taunton)
  2. Subject: Re: Passing on a request about sun au files.
  3. Date: 7 Nov 91 15:19:35 GMT
  4.  
  5. > I have a large collection of Sun .au files and I want to be able to use them
  6. > on my Archimedes.
  7.  
  8. I looked again at some Sun documentation on this today.  I think the
  9. following is correct....
  10.  
  11. For .au files created on SparcStations under earlier versions of SunOS
  12. (4.0.3c) there is no header on the files.  For later versions, there
  13. is a file header which gives details of the format of the data:
  14. unfortunately the full structure of this header is not documented and
  15. its overall size is said to be variable.  Instead Sun supply (the
  16. binary code of) routines to read & write file headers, which is not
  17. specially helpful for use outside SunOS.  However they do say that the
  18. format is a subset of that used by NeXT.
  19.  
  20. It seems likely that the raw data format is the same for all current
  21. .au files, since Sun's standard hardware supports only one sampling
  22. rate, and audio device drivers up to and including 4.1 only support
  23. one encoding method though the SparcStation hardware apparently
  24. supports two.
  25.  
  26. Here then are the details of the raw data format, as extracted from
  27. the Sun docs:
  28.  
  29.     sampling rate  8kHz (that's 8000 Hz, not 8192Hz)
  30.     sample format ISDN m-law companding (8-bits pseudo-log)
  31.  
  32. (m-law = mu-law = u-law, I believe: it is pronounced "mew-law", i.e.
  33. from the Greek letter mu, which looks a bit like a u, hence the funny
  34. variations)
  35.  
  36. Happily, mu-law encoding is what is used by the VIDC sound output
  37. system in all Acorn's 32-bit machines.  However the order and coding
  38. of the bits is different from Sun's. The Sun format for each sample
  39. byte is:
  40.  
  41. Bit:       7  6 5 4 3  2 1 0
  42.         +----+-------+------+
  43.         |Sign| Chord |Offset|
  44.         +----+-------+------+   
  45.  
  46. Sign = 1 means positive, = 0 means negative.  Both Chord and Offset
  47. are encoded as the 1's complement of the respective binary values,
  48. i.e. for Chord 0, Offset 0, the bits are all 1, whereas for Chord 7,
  49. Offset 15 the bits are all 0. [I won't bother explaining here what
  50. chord & offset mean.]
  51.  
  52. In VIDC-1a format, as used on all Acorn product machines (but not on
  53. some early prototype hardware) the format is:
  54.  
  55. Bit:     7 6 5 4  3 2 1  0
  56.         +-------+------+----+
  57.         | Chord |Offset|Sign|
  58.         +-------+------+----+
  59.  
  60. Sign = 0 means positive, = 1 means negative.  Both Chord and Offset
  61. are encoded as direct binary, i.e. Chord 0 has bits 7..4 all 0.
  62.  
  63. The reason for the different bit ordering is that it makes certain
  64. common signal synthesis computations simpler on ARM (there's the
  65. advantage of designing your own hardware!).
  66.  
  67. To convert from Sun format to Acorn VIDC format, you need to rotate
  68. each byte left by one bit and bitwise complement the whole byte.  This
  69. turns out to be pretty easy.  Here is a little program I wrote to do
  70. this: it is written in PCC style C (boo, hiss!) and runs on RISC iX.
  71. Converting to ANSI C, and for use under RISC OS should be fairly
  72. simple.
  73.  
  74. Obviously, you'll have to work out for yourself where any .au file
  75. header ends and the real data begins...
  76.  
  77. ----------------------------------------------------------
  78. /*
  79.  * stov.c: convert SparcStation audio data on stdin 
  80.  *         to Archimedes (VIDC) format on stdout.
  81.  *
  82.  * Mark Taunton, January 1991.
  83.  */
  84.  
  85. void *malloc();
  86.  
  87. #define BSZ 4096        /* Convenient for RISC iX's sound interface */
  88.  
  89. main (argc, argv)
  90.   int argc;    
  91.   char **argv;        
  92. {
  93.     /*
  94.      * Note that malloc always returns a word-aligned pointer.
  95.      */
  96.     unsigned char *buff = (unsigned char *)malloc (BSZ);
  97.     int n;
  98.     while ((n = read (0, buff, BSZ)) > 0)
  99.     {
  100.     unsigned int *wp = (unsigned int *)buff;
  101.     unsigned int *lim = (unsigned int *)(buff + ((n + 3) & ~3));
  102.     /*
  103.      * In the following loop we convert 4 bytes at once because
  104.      * it's all pure bit twiddling: there is no arithmetic to
  105.      * cause overflow/underflow or other such nasty effects.  Each
  106.      * byte is converted using the algorithm:
  107.      *
  108.      *   output = ~(((input >> 7) & 0x01) | 
  109.      *              ((input << 1) & 0xFE)  )
  110.      *
  111.      * i.e. we rotate the byte left by 1 then bitwise complement
  112.      * the result.  On ARM the actual conversion (not including
  113.      * the load & store) works out to take all of 4 S-cycles, and
  114.      * since we are doing 4 bytes at once this really ain't bad!
  115.      * Note that we don't worry about alignment on any odd bytes
  116.      * at the end of the buffer (unlikely anyway), we just convert
  117.      * all 4 bytes - the right number still get written.
  118.      */
  119.     unsigned int xm = 0x01010101;
  120.     do
  121.     {
  122.         unsigned int ss = *wp;
  123.         *wp++ = ~(((ss >> 7) & xm) | (~xm & (ss << 1)));
  124.     } while (wp != lim);
  125.     write (1, buff, n);
  126.     }
  127. }
  128.  
  129. -----------------------------------------------------------------
  130.  
  131.  
  132. From: mark@acorn.co.uk (Mark Taunton)
  133. Date: 7 Nov 91 16:03:32 GMT
  134. Organization: Acorn Computers Ltd, Cambridge, UK
  135.  
  136. As a P.S. to my posting on Sun audio file format, here's a little tip.
  137. To make low-sample-rate mono audio data (such as Sun format, at 8KHz)
  138. sound rather better through VIDC, simply repeat each audio sample in
  139. the stream and double the output sample rate.  The difference is quite
  140. marked.  Further slight improvement is possible through replicating
  141. more times, but going above a factor of 3 probably isn't worth it for
  142. 8KHz samples.  This sort of thing may perhaps be (and if not, probably
  143. ought to be) available as an option in sample players....
  144.  
  145. -- 
  146. Mark Taunton                Email: mark@acorn.co.uk
  147. Acorn Computers Ltd            Phone: (+44) 223 214411
  148. Cambridge, UK                Fax:   (+44) 223 214382
  149.  
  150.  
  151. From: wsinda@wsintt02.info.win.tue.nl (Dick Alstein)
  152. Subject: Conversion of Sun sound files to Arc format
  153. Date: 11 Nov 91 12:55:29 GMT
  154. Reply-To: wsinda@info.win.tue.nl
  155.  
  156. It's a bit late, but in response to questions about transferring Sun 
  157. sound files to RiscOs, here is a very small Basic program to do the 
  158. conversion. The output file can be read by !Armadeus, but you should 
  159. set the sample frequency to 8000 Hz by hand. (The file contains raw 
  160. data, no header.) After that, you can save it in another format.
  161.  
  162. ----------------------------------------------------------------
  163.  
  164. REM >SunToArc
  165. REM converts Sun sound files to Arc format
  166.  
  167. INPUT "Input from file: "in$
  168. INPUT "Output to file : "out$
  169. I%=OPENIN in$
  170. O%=OPENOUT out$
  171. WHILE NOT EOF#I%
  172.   B%=BGET#I%
  173.   C%=(B%>>7) OR ((NOT (B%<<1)) AND &FE)
  174.   BPUT#O%,C%
  175. ENDWHILE
  176. CLOSE#I%
  177. CLOSE#O%
  178. END
  179.  
  180. ----------------------------------------------------------------
  181.  
  182. Dick Alstein
  183. wsinda@info.win.tue.nl
  184.  
  185.